查看原文
其他

MySQL5.7中InnoDB不可不知的新特性(有彩蛋)

2016-09-05 赖铮 DBAplus社群



本文根据DBAplus社群第73期线上分享整理而成,文末还有书送哦~


讲师介绍
赖铮

Oracle InnoDB团队

Principle Software Developer


  • 曾任达梦、Teradata高级工程师,主要负责研发数据库执行引擎和存储引擎,十年以商数据库内核开发经验。


大家好,首先非常感谢社群的引荐,让我有机会在这里跟广大的DBA群友们交流。


今天的分享主要是针对MySQL5.7中InnoDB的新特性,InnoDB大家都应该非常熟悉,作为MySQL的存储引擎,而且现在变成默认的存储引擎,它为MySQL提供了强大的存储支持。伴随着MySQL从5.6演进到5.7,InnoDB 也有了一些新的变化。今天想跟大家分享的就是InnoDB在5.7中的这些变化。


我主要从性能和功能两大方面来给大家介绍:

1、性能提升(事务优化,临时表优化等)

2、新功能(透明压缩,加密,虚拟列等)


一、性能提升


首先,是性能方面。在5.7中,我的老板(大牛)做了一个很重要的工作,就是对InnoDB的事务(transaction)进行了优化。


1事务优化



在这方面他做的第一件事情就是创建事务池(Transaction Pool),这样就能减少很多事务创建和释放的开销。



他做的第二件事情就是优化了事务的生命周期管理。所有事务首先都默认为是只读事务,这样这些事务就不会和其他事务冲突,只有当此事务开始一个写操作时才认为它是一个读写事务。



另外,对事务的优先级也有了一些调整。


接下来我们看看经过这些修改之后,性能有些什么变化。



图上我们可以看到对于单点查询,sysbench oltp测试中,5.7可以达到1.6MQPS,比5.6有接近3倍的性能提升!



对于只读事务,我们用sysbench oltp测试下,5.7比5.6有超过一倍的性能提升!

 


而对于读写事务,我们也有50%左右的性能提升。是不是很强劲?当然,这只是其中一项性能优化,接下来还有更精彩的。


2临时表优化


我们在5.7中另一项重大性能优化是对临时表达优化。



在5.7中,我们将临时表从数据字典中分离出来,这样,临时表就不会跟其它正常表争抢数据字典的锁。同时,我们还将临时表的表空间跟普通表空间区别开来,以减少I/O的开销。



对于临时表的DML操作,我们只记录Undo日志,不记录Redo日志,因为,临时表不需要在Crash的时候Recovery,但是它需要rollback。这样也减少了大量的日志开销。



这张图显示了5.7的临时表create和drop的性能提升,这个应该是重复几万次create和drop所耗费的时间。5.7快到飞起来!



这是对临时表插入5M行当数据的测试,一倍以上的提升。



这是删除,开销减少了75%左右。



update,减少40%左右。所以,如果大家在应用中会使用InnoDB的临时表,那这个优化就能带来很大的好处。



刚才谈到的这个优化实际上不光是对InnoDB的临时表有用,还对一种大家平时看不见的表,优化器用的缓存表也有好处。之前,MySQL的优化器是用MyISAM来缓存SQL执行的中间结果集的, 现在,采用了InnoDB优化后的临时表,大家可以看图,明显快多了嘛!


好了,介绍完两个最大头的性能优化点,接下来我们浏览一下其他一些也非常重要的性能优化工作。


3其他性能优化工作


  • 缓冲区



这个是对于缓冲区的优化,页的reference count采用了原子操作,可以极大的提高这个计数器的操作效率。可以看到,这个优化最重要的是解决在12核甚至更多核机器上性能问题。 


同时,也对原来的刷写算法做了优化,提升了刷写效率。



缓冲区刷写采用多线程,而且可以配置线程数,同样能提高刷写效率。


  • Redo日志的I/O



对于Redo 日志的I/O,我们不仅解决了一些bug而且还优化了checksum以及mutex的算法。


  • Memcached 插件



得益于前面介绍的只读事务的优化,InnoDB的Memcached 插件也有了性能的飞跃,现在已经可以达到1.1M QPS。建议大家尝试一下,特别是对数据量很小, 但访问非常频繁的只读操作,可以采用InnoDB的Memcached插件。



这是memcached的测试结果,性能大幅提升。


  • 索引上的锁



这项优化是针对索引上的锁,一个非常复杂但是值得的优化。


  • DDL和truncate的优化



对于DDL和truncate的优化,现在truncate可以做到原子操作了,之前truncate中如果crash了,会导致出错。alter table也支持了更多新操作。



更快的DDL,这里主要指的是Alter table增加索引之类的操作。原来建索引是读一行插一行,现在是读一批,排序再批量插入。所以,性能有了170%的提升。


呵呵,这下,大家增加一个索引就快多了。


  • AHI



对于AHI的优化主要是将原来的哈希索引拆分成多个。


对于性能的优化这一部分就介绍到这里,总结一下,就是InnoDB在5.7中对性能做了一些非常重大的优化, 不光可以大幅加速数据的访问和存储的速度, 还能让大家节省很多日常维护的时间。


接下来,再讲讲我们在5.7中增加了哪些新功能。


二、新功能


1分区功能



首先是分区功能。以前,InnoDB内部是没有分区的,大家看到的都是在InnoDB外面做的分区。而现在,InnoDB原生支持了分区。


这样带来的好处是,减少了内存开销。以这样一个8k的分区的表为例,当打开十个实例的时候,可以减少90%的内存开销。




而且现在我们还可以对一个单独的分区做import/export了。



对于分区也支持了ICP和使用HANDLER来访问了。


2表空间管理



接下来一个新功能是表空间管理。其实这个不是什么新功能,只是让大家以更为习惯的方式来管理表空间。


3动态调整缓冲区的大小


再接下来这个功能,我想大家肯定会喜欢,就是动态调整缓冲区的大小。



大家再也不用关数据库,改配置文件,再启动数据库来修改缓冲区的大小了,so easy!


4日志管理



日志管理的新功能是自动截断,这样日志文件就不会再不停的增长了。这个功能我想大家也应该挺喜欢。


5数据页



支持更大的数据页。之前我们支持的是4k,8k,16k,现在可以支持32k,64k了。这样一些blob数据就可以直接存在页里,访问起来更快。


6对GIS的支持



在5.7中最大头的新功能是对GIS的支持,主要由同事Jimmy和我来完成。


我们在InnoDB内部实现了基于R-tree的空间索引,这样用户就能很方便的查找地理信息数据了。



比如:查找以我为中心,周围2公里范围内的饭店之类的操作将变得异常迅速。


7虚拟列和虚拟列上的索引



5.7中还有一个大头功能是虚拟列和虚拟列上的索引。也就是对于那些可以通过其他列的数据计算出来的列,大家可以创建一个虚拟列,它实际上是不存储数据的,每次读这个列都是临时在InnoDB内部计算出来。这个功能是客户要求的,但我不知道这里的同学是不是对此有需求。


8透明加密



为了让用户的数据更加安全,5.7中InnoDB实现了透明加密。(这个是我干的)



用户只需要在建表时加上加密选项,该表就被加密了,这样,就算你的ibd文件被偷了,别人也无法获得任何信息。


9全文索引



对于全文索引,5.7中开始可以支持外部解析器。



比如说n-gram。



又比如说MECAB。


10 新存储设备



对于新存储设备的支持方面,我们在5.7中支持了原子写入,在NVMFS上关掉了DW buffer。



11 数据压缩


另一个重要的新功能是新的数据压缩方法。基于页IO的压缩,也就是说,数据的压缩和解压发生在页IO的过程中。我们利用了一些文件系统的Punch Hole(文件打洞)功能来辅助实现这一新功能。



这里不详细介绍其实现方法了,总之效果就是文件更小,效率更高。


这里还有一些其他功能就不一一列举了,大家可以稍微浏览一下看看有没有自己感兴趣的,尤其是PFS这块,对于运维来说应该有帮助, 可以让DBA更多的了解当前系统的状态。






我今天要讲的内容大体就是这么多。总结一下,InnoDB在5.7中在性能和功能方面做了很多工作,非常期待大家的试用和反馈。


Q&A


Q1:互联网金融企业,用MySQL 5.7的话,老师在高可用组件方面有什么推荐?

A1:我觉得对于5.7来说,高可用方面在InnoDB这部分并没有做太大的改进。所以,总体来说,5.7在高可用方面会更为可靠和高效,但是,5.7在replication方面有很多提升。至于推荐什么高可用方案,我想还是要根据实际的应用情况来定。


Q2:分区表的分区键,可以是多个列吗?

A2:可以多列。


Q3:虚拟列 都是临时在InnoDB内部计算出来 ,是否意味著会消耗更多的CPU资源?

A3:有影响,但不大。


Q4:官方版本为什么不把TokuDB带到版本里去?

A4:这个是管理层决定的事情,我想他们有自己的考虑,可能主要是基于商业目的,而非技术原因。


Q5:关于MySQL优化,和原理解压,有没有推荐的书籍?

A5:市面上关于MySQL优化的书有很多,比如《高性能MySQL》,但是,我想多看看一些相关文章,结合自己的工作实践会更有效果。


Q6:MySQL有没有什么好用的性能监控工具,类似于Oracle的AWR报告这种?

A6:目前官方是没有的,可以找找其他的监控工具。


Q7:对事务的优先级也有了一些调整。是如何调整的呀?

A7:这个主要是提高了一些事务的优先级,比如说复制的GCS事务,这些高优先级事务可以有一些特权,比如说可以跳过排队的队列,使得高优先级的事务可以优先执行。


Q8:创建表加密时可以指定只加密部分列吗?

A8:我今天说的这个表加密是在I/O层进行加密的,不能针对列进行加密,它只针对表,如果要只加密部分列,可以使用MySQL的 加密函数,在插入数据时进行加密。


Q9:数据库从5.6迁移到5.7要注意一些什么问题?

A9:升级工作正常来收不会遇到大的问题,因为我们在发布版本的时候都会有相应的升级测试,只有万一碰到什么问题,也可以具体情况具体分析,实在不行,可以告诉我,看是不是有bug需要修改。


Q10:truncate table加入了原子性,那速度是否会变慢?

A10:这个工作只是保证了truncate的操作不会导致问题。


Q11:5.7在dblink方面是否有改进?

A11:这方面的改进我没有听说。


Q12:听说sap的HANA内存数据库处理效率很高,请问MySQL(或Oracle)有无与其它产品做过对比测试(如高并发,性能等)呢?

A12:HANA 是列式存储的内存数据库,体系结构和MySQL完全不一样。因为不是同类型的产品,我们没有专门针对HANA做对比测试。

好书相送

在本文评论区留下足以引起共鸣的真知灼见,并在本文发布后32小时之内成为点赞数最多的前2名,可获得以下书籍一本~


特别鸣谢清华大学出版社为本次活动提供图书赞助。

精选专题(点击蓝色标题可阅读全文)

◆  近期热文  ◆  

微信支付商户系统的架构揭秘

RTO零切换!山东移动双活容灾最佳研究和实践(上)

引以为戒:记一次心惊肉跳的服务器误删文件的恢复过程

高可用系统设计精要: 定个能达到的小目标,比如先读完本文

解DBA之惑:数据库承载能力评估及优化手段


◆  专家专栏  ◆  

杨志洪杨建荣陈能技丁俊卢钧轶李海翔

魏兴华邹德裕周正中高强白鳝卢飞王佩


◆  近期活动  ◆  

Gdevops全球敏捷运维峰会广州站


峰会官网:www.gdevops.com

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存